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Management of service products in a network 

background of the invention 

The invention relates to methods and equipment for managing net- 
work service products. Computer models exist for managing telecommunica- 
5 tion networks and basic bearer services. For example, PCT application WO 
01/54350 discloses a system and a method for modelling communication net- 
works. 

Prior art modelling systems are somewhat restricted, however. From 
an end user's point of view, a service product may appear homogenous or 
10 monolithic. That is, a mobile subscriber may receive a personalized weather or 
stock market report without thinking or knowing that the service product con- 
sists of several very different components, namely a network service, an appli- 
cation logic and a content. The content is the updated report. The application 
logic is the logic that detemnines the content. The network service provides the 
15 underlying platfomn for delivering the content to the subscriber. Typically, a 
different organization is responsible for each component. A network operator 
provides the network service. A content provider provides the content, but typi- 
cally does not know how to deliver the content to subscribers in various net- 
works. An application designer integrates the content with the network but 
20 does not know all the details of the content or the network(s). 

Thus a problem of the prior art modelling systems is that they do not 
cross the boundaries between organizations (network operator, application 
designer, content provider) and each organization only models its own part of 
the whole. 

25 BRIEF DESCRIPTION OF THE INVENTION 

An object of the present invention is to provide a method and an 
apparatus for Implementing the method so as to alleviate the above disadvan- 
tages. The object of the Invention Is achieved by the methods and equipment 
which are characterized by what is stated in the independent claims. Prefen-ed 
30 embodiments of the invention are disclosed in the dependent claims. 

The invention is based on the idea of modelling network services 
across the traditional inter-organization boundaries. In other words, a common 
model models the network services that are provided by the network operator, 
applications that are typically provided by application developers and content 
35 that is typically provided by content providers. Each of the three parts of the 
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whole, ie network services, applications and content, are modelled as compo- 
nents. The components have well-defined and published interfaces. A benefit 
of the common model modelling all parts of the whole is a better understanding 
of the whole. Further, various interactions between components in different 
5 parts of the whole (such as applications and network services or applications 
and content) become more readily visible. An advantage of using components 
with well-defined interfaces is that the components can be reused to create 
additional services. 

Prior art modelling systems do not have integrated basic network 

10 services or value-added services (applications) because the network operators 
and application developers have each provided their own models. The inven- 
tive technique enables modelling basic network services and value-added ser- 
vices in a common model which helps to integrate the value-added services 
with the underiying network-level services. In addition, the inventive model at 

15 least provides well-defined interfaces for content components and, preferably, 
models the content components in the same common model. A benefit of the 
common model modelling basic network services and value-added services is 
that content providers can use the common model to develop and test content 
components without access to real network resources. 

20 Some essential terms of the invention will be described first. A soft- 

ware component, as used in contexts like "network service component", "appli- 
cation component" and "content component", means a software collection with 
one or more well-defined interfaces. As used in this context, a well-defined in- 
terface means an interface that adheres to certain common rules, whereby 

25 each component can be referred to in a systematic manner. Well-defined inter- 
faces can be open or proprietary (vendor-specific). 

A network service component is an abstraction that defines a net- 
work service (as distinct from higher-level services, such as weather fore- 
casts). The application component provides value-added services, that is, ser- 

30 vices beyond basis network or bearer services. The content component is what 
the subscriber is really Interested in, such as a weather or stock market report, 
a piece of music or video, etc. 

An aspect of the invention is a method for modelling a high-level 
service to be provided via a telecommunication network, the method compris- 

35 ing: 

modelling the high-level service by a software component model 
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comprising at least one of each of the following: 

- a network service component 

- an application component; and 

- a content component; 

5 the software component model further comprising relations between 

said components. 

Another aspect of the invention is a service topology database for 
storing and distributing information on service components which are operable 
to act as components for building high-level services in a network, the service 
1 0 topology database comprising: 

a) network service component data comprising for each of several 
network service components: 

- identification infonmation; 

- status information; 

15 - usage information; and 

- parameter infomiation indicating how the component can be pa- 
rameterized to suit different service products; 

b) relationships between service components, the relationships indi- 
cating restrictions related to use of components for a service product; 

20 c) service product data comprising for each of several service prod- 

ucts: 

- identification information; 

- status information; 

- usage information; and 

25 - information on network service components used for the service 

product; 

- parameter information on the used service components; 

- service component level information comprising at least tariff in- 
fonmation; and 

30 - deployment rules determining how the service product is deploy- 

able in the network. 

Yet another aspect of the invention is a service planning unit for 
planning high-level service products to subscribers in a telecommunication 
network, wherein the service planning unit comprises or is closely connected 

35 to: 

a service topology database for storage and on-line distribution of 
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information on service components which are operable to act as components 
for building high-level services in a network; 

a service simulation and testing section for providing functions relat- 
ing to verification of service products; 
5 a service deployment section for deploying services in the telecom- 

munication network; 

a service assurance section for monitoring and reporting of the ser- 
vice products; and 

a usage reporting section for processing reports on the service 
10 products' perfomnance and usage. 

As used herein, the expression "closely connected" means under 
common administration and having on-line access to each others' data. 

BRIEF DESCRIPTION OF THE DRAWINGS 

In the following the invention will be described in greater detail by 
15 means of preferred embodiments with reference to the attached drawings, in 
which: 

Figure 1 illustrates a basic concept of the service product modelling 
according to the invention; 

Figure 2 illustrates the various stages in the development of service 
20 components; 

Figure 3 illustrates an exemplary network arrangement in which the 
invention can be used; 

Figures 4 illustrates development of application components; 
Figure 5 illustrates testing of service components; 
25 Figure 6 illustrates deployment of service components; 

Figures 7 illustrates development of service products; and 
Figure 8 illustrates deployment of service products; 
Figure 9 shows the composition of the end-user service in more de- 
tail than Figure 1 does; and 
30 Figure 10 illustrates how service components can be stored in re- 

positories that enable re-using of the components. 

DETAILED DESCRIPTION OF THE INVENTION 

Figure 1 illustrates a basic concept of the service product modelling 
according to the invention. A service product model according to the invention 
35 comprises at least the following types of components: 1) network service com- 
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ponent, 2) application component and 3) content component. A gross analogy 
to goods delivery systems is that the network service component corresponds 
to transport infrastructure (roads, railways, vehicles, etc.) The application com- 
ponent corresponds to transportation logistics. The content component corre- 
5 spends to the actual goods being delivered. By way of example, the bottom 
section of Figure 1 shows iconic representations of the meaning of network 
service, application and content. 

A network service component is an abstraction that defines a net- 
work service (as distinct from higher-level services, such as weather fore- 

10 casts). The network service is defined by a set of parameters describing, for 
example, the quality, capacity and security of the network service. The network 
service component helps to hide the complexity of the network from the service 
management. By way of example, ttie parameters comprise Identity data and 
component data. The Identity data typically comprises 1) name, 2) status and 

15 3) location infonmatlon. The name is the component's identifier. The status in- 
fomiation Indicates active or inactive status and, optionally, version infomnation 
unless the version is indicated In the identity data. The location indicates where 
the component is located. The component data may comprise 1) deployment 
rules, 2) quality policy rules, 3) security rules, etc. 

20 The application component provides value-added services, that is. 

services beyond basis network or bearer services. For example, the value- 
added services are used by MiVIS (multimedia messaging specifications), IMS 
(IP Multimedia Subsystem) and MCD (Mobile Content Delivery) solutions. The 
application component comprises 1) application identity data, 2) the application 

25 logic, 3) application component data and 4) metadata. The application identity 
data typically comprises infomiatlon similar to identity data of the network ser- 
vice, ie. name, status and location infomnation. The application logic is the en- 
gine that drives the application. Typically, the application logic is implemented 
In a high-level language, such as Java. The application logic can also be 

30 based on more or less fixed network element functions, such as call control 
functions. The application component data comprises configuration parameters 
and application data. The metadata comprises data about elements, including 
their descriptions, ownership, access paths, access rights and data volatility. 
The metadata comprises 1) application metadata, ie, parameters used In the 

35 application, 2) content metadata, ie, content component parameters used In 
the content component, and 3) verification information which is used when the 
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data is set up, for example, in tlie service provisioning system. 

The content component is wliat the subscriber is really interested in. 
The content component comprises 1) content component identity data and 2) 
content component data. The content component identity data typically com- 
5 prises information similar to identity data of the network service, ie. name, 
status and location information. The content component data comprises 1) 
configuration parameters and 2) content data. 

In addition to the three kinds of components (network service, appli- 
cation, content), the model according to the invention comprises the relation- 
10 ships between the components, in the example shown in Figure 1, the service 
product under study (or its model) comprises two network service components, 
three application components and one content component. 

Figure 2 presents an overall view of the various stages in the devel- 
opment of service components. The various stages will be further illustrated In 
15 connection with Figures 4 through 8. 

Figure 3 illustrates an exemplary network anrangement in which the 
invention can be used. In the example described herein, service management 
is divided into several functional blocks: service topology, service planning, 
service simulation and testing, service deployment, service assurance control, 
20 and service usage measuring. Reference numerals 1 to 14 depict actions 
needed to develop and provide service products. 

The service topology database ST is a central element of the ser- 
vice management model. The service topology database ST contains defini- 
tions of each service product, both from the point of view of business deveiop- 
25 ment and implementation/operations. Service topology is then available, in an 
on-line form, for all the entities in the arrangement shown in Figure 3. The ser- 
vice topology database ST will be further illustrated in connection with Figure 
10. 

Thus an aspect of the invention is a service topology database for 
30 storing and distributing Information on service components which are operable 
to act as components for building high-level services in a network, the service 
topology database comprising: 

a) network service component data comprising for each of several 
network service components: 
35 - identification information, 

- status information, 
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- usage information, and 

- paranneter information indicating how the component can be pa- 
rameterized to suit different service products, 

b) relationships between service components, the relationships indi- 
5 eating restrictions related to use of components for a service product, 

c) service product data comprising for each of several service prod- 
ucts: 

- identification information, 

- status information, 

10 - usage information, and 

- information on network service components used for the service 

product, 

- parameter information on the used service components, 

- service component level information comprising tariff infomnation 
15 and, optionally, product launch and/or business target infomnation, etc. 

- deployment rules determining how the service product is deploy- 
able in the network. 

A service planning section SP provides functions for defining service 
products to the service topology through a service planning interface. The ser- 

20 vice planning section SP provides a generic extensible interface that can be 
used for defining several types of service products. The service planning inter- 
face can be divided to a business development part BD (action 1 in Figure 3) 
and an operations part (action 2). The business development part accounts for 
the general product requirements with business significance and for all the 

25 product aspects that are visible to the end user. The operations part O ac- 
counts for the technical implementation and deployment of the sen/ice product. 
The service planning is thus a joint effort between network development and 
operations. 

A service simulation and testing section SS provides functions for 
30 the verification of sen/ice products. Herein, service simulation (action 3) refers 
to the Initial verification of the service definition in the service topology, ie be- 
fore the service product is deployed to the network. It may provide feedback to 
business development and operations to modify the service definition. After 
actions 1 to 3 are successfully perfomned, the service product Is ready to be 
35 deployed to the network. 

Service testing (action 11) refers to the final testing of the service 
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product after it has been deployed either to the separate testing networic or to 
the live network. After successful service testing the service product can be 
published for customers. 

Service deployment can be seen as mediation between service to- 
5 poiogy and the network. Service deployment realizes the definition of the ser- 
vice topology as the actual network configuring tasks. That is. the service 
components are employed and parameterized in order to implement the ser- 
vice product. Service deployment includes: 1 . determining the parameters of 
the network service components (action 5), which is typically perfonned by 
10 means of network management systems, and 2. determining the parameters of 
the application components (action 6). Service deployment may also include 
publishing the service topology information for various support systems (action 
7) dealing with charging and prepaid services, subscription management, cus- 
tomer relationship management, or the like. 
■•5 Service assurance control enables the monitoring and reporting of 

the service products, including both perf^omnance reporting and usage report- 
ing. In the deployment phase, the assurance-related configuring is done to eg 
different monitoring tools in network management systems (action 6). This 
way, the linking of network perfomnance can be linked to the perfomiance of 
20 service products. After the service product is deployed and published to the 
users, the service-product-specific service assurance and usage data is col- 
lected from the network (action 13). Furthemnore, the service assurance con- 
trol interacts with the service level assurance (SLA) systems, enabling the link- 
age of service products with the different service level agreements. A service 
25 level agreement is an agreement between a user and a service provider, the 
agreement defining the service content, the responsibilities of both parties, and 
the metrics and related target levels for service performance. 

Usage reporting supports the lifecycle management of service prod- 
ucts by providing processed reports on the service products' performance and 
30 usage. The focus is on the information that enables assessing the profitability 
of the service products. 

Figures 4 through 8 further illustrate the various stages in the devel- 
opment of service components. Figure 4 illustrates development of application 
components. In Figures 4 to 8. "SeMa" means service management. In a first 
35 step, the application developer implements the application and metadata with 
application development tools. The application development tools can be 
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commercial off-the-shelf software tools, such as Jbullder. The application and 
metadata can be stored temporarily in the application directory, which forms a 
part of the tools. 

In a second step, the application developer stores the application, 
5 metadata and all related information to the application repository, after which 
the application component can be tested. The application repository is a logical 
repository where the application components are stored. (A repository is a 
well-known concept in software component technology.) 

Figure 6 illustrates testing of service components. In a first step, the 
10 service component tester selects the service component(s) to be tested. Ser- 
vice components can be application components, network services compo- 
nents or content components. 

In a second step, the service component tester begins to test the 
service component. Next, a protocol simulator is started according to the test- 
is able service component. During the test of the service components, the service 
component testing environment stores the verification reports In a report re- 
pository. 

Figure 6 illustrates deployment of service components. In a first 
step, the service component deployer deploys the service components to the 

20 underlying network like IMS and MCD. After the service component is de- 
ployed, the service component is published to the service product, network 
service component and content component. Next, the service component de- 
ployer deploys the part of the service component to the underlying IP network. 
The IP network consists of elements like IMS and MCD. Third, the service 

25 component deployer publishes the part of the service component to the man- 
aged service components. The environments can be service product, network 
service component, application component and content component environ- 
ment. 

Figure 7 illustrates development of service products. In a first step, 
30 the service product developer develops the service product for selected ser- 
vice components needed by the service product. After that, the service product 
can be published to the management subsystem. In a second step, the service 
components are selected to be part of the service product. The service com- 
ponent can be network service component, application component and/or con- 
35 tent component environment. 

Figure 8 illustrates deployment of service products. In a first step. 
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the service product deployer publishes the service products to the network 
elements that use the sen/Ice product like SBS and CRM. SBS (Subscription 
Brokering System) is a subscription management solution for All-IP, 3G and 
GPRS and GSM network customers who need to provide end-to-end subscrlp- 
5 tion management, profile brokering, more controlled and richer self-service and 
provisioning capabilities. Next, the service product environment stores the in- 
formation that the service is published to the logical repository of the service 
products. In addition, the service product environment stores and publishes the 
service product the to external system like SBS. 

10 Figure 9 shows the composition of the end-user service in more de- 

tail than Figure 1 does. An end-user sen/ice product is ultimately built from one 
or more network service components, one or more application components 
and one or more content components. In Figure 9, the notation "1 ..n" means 
one or more, but the n need not be the same number everywhere. The nota- 

15 tion "0..n" in connection with the content component means that some benefits 
of the invention are achieved by modelling the network service components 
and application components in a common model. That is, applications and ba- 
sic network services can be modelled and simulated in the same model. Pref- 
erably, the model also comprises at least one content component. 

20 Figure 10 illustrates how service components can be stored in re- 

positories that enable re-using of the components. 

It Is readily apparent to a person skilled in the art that, as the tech- 
nology advances, the inventive concept can be implemented in various ways. 
The invention and its embodiments are not limited to the examples described 
25 above but may vary within the scope of the claims. 

Acronyms (some are not official): 

CRM: Customer Relations Management 
IMS: IP Multimedia Subsystem 
IP: Internet Protocol 
30 MCD: Mobile Content Delivery 

MMS (Multimedia Messaging Specifications) 
SBS: Subscription Brokering System 
SLA: Service Level Assurance 



